Search

#反求諸己

我想特別 highlight 這一段,給所有的工程師朋友參考。
  • Share this:

#反求諸己

我想特別 highlight 這一段,給所有的工程師朋友參考。

「科學家為什麼不能只寫 "行內人"懂的東西?幹嘛花力氣跟行外的一般人講解我在做什麼?一部分的原因是,你的研究(經費)是受到大眾支持的(稅金),你需要好好的跟你的老闆(繳稅的大家)介紹你在做什麼,有什麼重要性,有什麼意思。當大家不能體會你的重要性,就是你的經費要結束的那一刻。

反過來說,當大家從這些科普書籍科普文章中知道這些研究是有趣而且重要的,自然就有可能出現支持科學研究的音量,產生正向循環。

就像Weinberg說的,你要溝通的對象都跟你一樣聰明,只是沒有受過這方面的專業訓練。你要用對方聽得懂的話跟他們溝通,而不是用自己的行話自己說自己的,然後抱怨我講的很認真為什麼大家都聽不懂。」

簡單的三段,字字珠璣!

➀ 你想要公司、老闆、PM、PO、stakeholder 來支持你引入的變革,來支持基礎建設的投資,不能一直怪他們不懂,不能只怪他們短視近利,覺得他們聽不進去。

能做的是,鍛鍊自己的表達能力、溝通能力、觀察能力,甚至還要培養自己的 creadit 以及跟他們的 trust 跟 relationship。因為這也是我們該做的事,不是只有技術。(這甚至稱不上是政治)

➁ 正向循環,一樣,如果沒有開始,沒有引入一個新的增強或減弱,來推動因果循環,就不會改變現狀,無法推動正向循環。這也是為什麼,我們通常會提: Show, Don't Tell。

一旦你先額外投入做出了一些我們彼此都關心的成果,搭配第一點的換位思考跟表達能力,正向循環的起點才會萌芽。

你都願意提前、額外投入心力開始去做出一些成果,也證明了你的動機,你的行動就是對這樣變革最好支持的證據。

➂ 其他人不是笨蛋,講行話只是一種「知識的詛咒」的現象,一切至少先反求諸己,看自己還有哪方面的能力可以提昇的(尤其是軟技能面的軟實力)。

同時也別忘了觀察力,因為真的仍有可能,你身處的單位或組織,在你竭盡一切能力都無法力挽狂瀾時,不要浪費自己的生命跟青春了,有學到東西、累積到經驗,去尋找更能讓自己發光發熱的舞台吧。

最後,如果你的過去一直都是在抱怨,每一間公司都沒有舞台讓你發揮,都無法讓你力挽狂瀾,通常就是:要嘛你判斷力有問題,從對公司的選擇就出錯了。要嘛你能力還有問題,不管是軟實力或是硬實力。

反求諸己,怪環境、怪他人總是比較簡單的路,然而那就是會讓自己停滯不前的路。

我想到之前跟 Odd-e 國外的同事聊到 coaching 或 training 費用定價的相關事情,有一句話我印象很深刻:

「當然你還是有可能會因為市場競爭,而需要降價、降低自己的bar 來獲得生存。

但永遠都別忘了,金字塔上層的需求一直都在的,我們接觸不到,不意味著它不存在。

而是我們還未擁有足夠的能力、資格,去服務他們,讓他們看見我們的能力足以滿足他們的目標。

永遠不要忘了讓自己持續精進,避免歸咎在環境、市場、他人,而是看自己還有哪些方面要調整、改善、學習。」

這一直都與 敏捷 中的「務實」相呼應著,反求諸己,往往是最務實的作法。

我還記得 Daniel 在培訓所作最後的 retrospective 時針對 action 的部份都會強調一點:「在沒有任何其他人的幫助下,可能是你的老闆、主管、產品經理或你的團隊成員,你能在未來一週,做點什麼改變與應用所學。」

那個前提就是立個旗子,讓自己先少點藉口。

有時,成果失敗了,不是真失敗。沒有行動,以及慣性把失敗的原因歸就在他人與環境上,才是導致失敗的根本原因。


Tags:

About author
我是 Joey Chen,闖蕩江湖的稱號是 91,熱血點火師,專門燃起大家心裡面的熱情與初衷。 目前為 Odd-e Taiwan 的負責人,同時也是 JetBrains 在台灣的培訓夥伴,至今也仍是熱愛學習與享受各種程式語言之美的 programmer。 身為敏捷教練,擅長 Agile、Scrum、LeSS 等敏捷文化與協作框架的落實與導入,如何讓大家 being agile 而不是 doing agile。同時喜歡結合各家所長,例如 Lean, Kanban 等,重點是持續改善、解決問題、端出成果,而不執著於某種特定方法論或框架。 身為技術教練,我也是極限編程(extreme programming)的狂熱者,我擅長用這些技術與工程實踐來提昇產品的品質、團隊的生產力、降低營運風險,因應市場與公司的商業目標,讓團隊能具有高適應與反應能力的基礎建設。例如 實例化需求、ATDD、BDD、TDD、重構、自動化單元測試/整合測試/驗收測試、CI/CD、code review、pair programming、mob-programming 等等。 同時,我也是推崇 極速開發 的 developer,追求從想法到產品程式碼的完成,中間的時間差能趨近於零,也就是劍隨心轉,想到哪,程式碼就長到哪的境界。從想法到實現中間的等待,其實在實務上佔了很大的 context switch 成本,如果能讓這段時間縮到最短,就能比其他人多嘗試更多種解決方案,進而挑選出最剛好的方案。 同時也是技術社群的活躍份子,從 2010 年開始連任九屆的微軟 MVP,兼任 MSDN 論壇板主,也曾經獲得年度 MSDN 文件庫刊登數量世界第一的榮耀。對微軟技術有愛,對 C# 有愛,對自動測試有愛,對重構與設計模式有愛。近年來對 Java, PHP, Python 也充滿濃厚的興趣,曾帶領客戶團隊中不會寫程式的 QA ,一起用 Python 完成超過百個 mobile UI 自動化測試。 擁有超過十年擔任開發團隊 tech leader, trainer, coach 與 mentor 的經驗,進行的企業內部與公開技術培訓課程已超過 100 場,培訓過的開發人員超過 1000 位,擔任研討會與社群活動的講師次數超過 30 次。 同時也是技術書籍的作者與譯者,與朋友合著的書籍包含《ASP.NET MVC 5:網站開發美學》、《ASP.NET MVC 4 網站開發美學》,翻譯的書籍有《單元測試的藝術-第二版》、《敏捷開發實踐》、《進入IT產業必讀的200個 .NET面試決勝題》。 如果想跟我即時互動,歡迎直接私訊或 email 至 [email protected]
請參考:https://tdd.best/about/
View all posts